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Abstract 

We present 11ISP, a novel architecture for Internet Service Providers suitable for installation in 
airports, hotels, conference centers, cafes, and office or apartment buildings. Users access a filSP 
via a low-cost, high-bandwidth LAN, e.g. Ethernet or WaveLAN. A router connects the filSP's LAN 
to a shared high-bandwidth access link (e.g., DSL or cable) to a conventional ISP For this service, 
a [iISP charges its clients. The architecture supports a variety of payment methods, both offline 
(e.g., cash, credit card, or billing to a hotel room account) and online (e.g., sCash, SET, IBM Micro 
Payments, or Millicent). p,ISPs use IPSec's IKE protocol for securely exchanging authentication 
keys with paying users. Paying users use IPSec 's AH protocol in tunnel mode to authenticate each 
packet they send. Therefore, [xISPs can easily detect and drop packets ofnonpaying users. A /iISP 
must present to users a certificate signed by a recognized authority, but a user may simply present 
a self signed certificate, as long as the user pays for service. Regardless of how online payment is 
implemented, it runs on the user's authenticated tunnel, and therefore can be securely bound to it. 
The p,ISP protocol allows users to monitor and control usage and supports recovery in case of a 
pISP or user computer crash. 

Keywords: Mobile access, access devices, electronic commerce, security and privacy. 

1 Introduction 

Users typically connect to the Internet via Internet Service Providers (ISPs). In the conventional 
ISP architecture, illustrated in Figure 1, each user pays for the installation and maintenance of an 
access link connecting the user's computer(s) to an ISP's POP (Point of Presence). Alternatives 
for access links include dial-up PSTN (Public Switched Telephone Network) or ISDN (Integrated 
Services Digital Network) telephone lines, dedicated telephone lines (e.g., Tl), DSL (Digital Sub- 



PSTN 




Access 
router 

Conventional 



Backbone 
router 



Internet ' 

Figure 1: Dial-up PSTN lines are still the most common ISP access links. They provide low 
bandwidth and usually require one access link and ISP account per computer. When the user is 
mobile, dial-up PSTN lines may be unavailable, inconvenient, or expensive to use. 

scriber Line), and cable. A contract between user and ISP lasts typically at least a month and often 
much longer than that. 

The conventional ISP architecture has two shortcomings. First, access link costs are significant, 
i.e., correspond to a considerable fraction of the user's total Internet connection cost. Second, 
mobility support is poor, especially for higher access bandwidths. On the one hand, dedicated 
telephone lines, DSL, and cable can provide high bandwidths, but are available only where the 
user installs them (e.g, office or home). On the other hand, dial-up lines allow access wherever 
there is a phone, but phones may be unavailable, inconvenient, or expensive to use and, in any 
case, provide low bandwidth. For example, the number and location of pay-phones in airports, 
conference centers, and cafes is often adequate for short conversations but inappropriate for laptop 
hookups and Web browsing. Wireless phones are convenient in such situations, but are expensive 
to use for more than a few minutes. Additionally, long-distance calls may be necessary to dial-up 
the nearest POP of the user's ISP. 

This paper introduces a novel architecture, /JSP, that overcomes the above-mentioned short- 
comings of conventional ISPs. A //ISP reduces access costs by amortizing among many users the 
cost of a high-bandwidth access link to a conventional ISP. Users access a /xISP via a low-cost, 
high-bandwidth Local Area Network (LAN), e.g., Ethernet or WaveLAN, as shown in Figure 2. 
The bandwidth dynamically allocated to each user is likely to be similar to that which many users 
enjoy at work, and much better than that afforded at home by a dial-up PSTN line. A router 
connects the //ISP's LAN to the shared high-bandwidth access link, which may be, e.g., DSL or 
cable. For this service, the /xISP charges its clients. The architecture supports a variety of offline 
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Figure 2: A //ISP amortizes among many users the cost of a high-bandwidth access link (e.g., 
DSL). //ISPs require little investment and space and therefore may be deployed widely and in 
convenient locations. //ISPs support mobile users by allowing short-term contracts. 



and online payment methods. //ISPs support the needs of transient (mobile) users because, unlike 
conventional ISP contracts, //ISP contracts can be short-term (e.g., may last only 15 minutes). The 
low investment necessary to set up a //ISP and the potential profitability encourage widespread 
deployment. 

A challenge in this type of architecture is how to prevent a nonpaying user from gaining free 
service or charging his or her Internet usage to a paying user. For example, if the //ISP's LAN uses a 
shared medium, e.g. Ethernet or WaveLAN, a nonpaying user n might be able to communicate with 
another host /z by (1) snooping in the LAN to find the IP address of an active (paying) user p, (2) 
sending packets to h by spoofing them, i.e., making the source address equal to p, and (3) receiving 
packets from h by snooping in the LAN to find packets with source equal to h and destination equal 
to p. The //ISP architecture uses IPSec's standard Authentication Header (AH) in tunnel mode 
[18] to solve this problem. //ISPs and paying users securely exchange authentication keys using 
IPSec's IKE (Internet Key Exchange) protocol [15, 24]. Paying users then use AH with such keys 
to authenticate each packet they send. No application (e.g., browser) modifications are necessary 
because IPSec is configured and operates at the network layer [19, 7]. Because AH authentication 
includes the packet's source address, and nonpaying users do not have authentication keys, the 
//ISP can easily detect and drop spoofed packets, shutting off nonpaying users. 

The //ISP architecture uses IKE with certificate-based authentication. A //ISP must present 
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to users a certificate signed by a recognized //ISP Certifying Authority (CA). Users, on the other 
hand, need not incur the cost or trouble of obtaining certificates from a recognized CA. A user may 
present to //ISPs a self-signed certificate and may thus remain anonymous if the payment method 
also preserves anonymity (e.g., cash or eCash [9]). 

A potential source of complexity and implementation difficulty is the need to accommodate 
within the architecture the many different usage metrics and payment methods that may be desir- 
able in a given //ISP. Usage metrics may be, e.g., elapsed or usage time, or number of bytes or 
packets transmitted. Payment methods may be offline (e.g., cash or credit card) or online (e.g., 
eCash [9], SET [29], IBM Micro Payments [16], or Millicent [12]). The //ISP architecture de- 
fines a carefully designed protocol that supports these and other options. In particular, the //ISP 
protocol does not require modifications in online payment method implementations, because the 
protocol automatically and securely binds online payment (however implemented) with the above- 
mentioned AH tunnel. 

Another potential pitfall is how to recover from computer crashes. In many scenarios, crashes 
are actually expected. For example, a guest at a hotel or conference center may turn her laptop 
on and off several times until her contract with the local //ISP expires. The //ISP protocol allows 
graceful recovery by issuing the user a receipt after the user pays. The //ISP authenticates the re- 
ceipt using a secret key. If the usage metric is simply elapsed time (flat fee until an expiration time), 
the receipt contains all the information necessary for recovery and, except for online payments, the 
//ISP need not commit user state to stable storage. Recovery of crashes between the time the user 
sends online payment to the //ISP and the time the user commits the respective receipt to stable 
storage is handled according to the respective payment method. 

As mentioned above, //ISPs use the services of conventional ISPs. //ISPs may be able to reduce 
substantially the cost of such services by implementing NAPT (Network Address Port Transla- 
tion) [30] in the router between the //ISP LAN and the shared high-bandwidth access link. In this 
case, all /iISP users use the same global IP address and appear to the conventional ISP as a single 
host. 

Cybercafes are a competing alternative to ISPs. Typically, cybercafes lease to users desktop 
computers connected to the Internet. Like //ISPs, cybercafes allow short-term service contracts. 
Cybercafes require much greater investment than do //ISPs because cybercafes own the computers 
used and need space for them, whereas //ISPs simply provide Internet access to user-owned laptop 
or desktop computers and therefore need negligible space. Consequently, //ISPs may be deployed 
more widely and in more convenient locations. An additional advantage of //ISPs is that users may 
find their own computers more familiar and secure to use than are those provided by a cybercafe. 
A hybrid service model, //ISP cafe, is also possible, and would accommodate the latter users as 
well as users who do not have their computers with them. 

Unlike conventional ISPs, cybercafes and //ISPs do not themselves provide to users local con- 
tent and email or Web page hosting services. However, this is becoming hardly a disadvantage, 
because users can easily find on the Web portals or servers that provide such services for free (e.g., 
www.yahoo.com, hotiuail.com, and www.geocities.com). Web-based services have 
the advantage of being accessible wherever the user may be. 

The rest of this paper is organized as follows. Section 2 gives an overview of the /JSP pro- 
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tocol and its phases. Sections 3 to 8 describe each of the phases in greater detail: networking 
configuration, secure tunnel establishment, control channel establishment, contract establishment 
and binding, usage metering, and settlement. Section 9 discusses implications of using NAPT, 
and Section 10 discusses some other variations in the /JSP design. Finally, Section 1 1 reports the 
performance of a prototype implementation, and Section 12 concludes. 

2 ^ISP protocol overview 

As shown in Figure 2, the main components of the /JSP architecture are a high-bandwidth LAN, 
a router, a server, a shared high-bandwidth access link, and a protocol for communication between 
user computers and the /JSP server and router. Although server and router can in general be 
implemented separately, in this paper we assume that the server is implemented within or as an 
adjunct to the router, and the term "//ISP" is used to refer to that combination when communicating 
with users. 

This section gives an overview of the //ISP protocol. Its design was influenced by the following 
constraints: 

• Use of standard hardware and protocols. //ISP access will typically be based on a shared 

medium, and it is tempting to design special network cards, protocols, tokens, or smart- ^ 
cards to guarantee secure access and payment in such networks. For example, cable access '4 
networks are also based on a shared medium and use special, certified cable modems and .$ 
a special protocol (BPI+ [4]) to secure communications between cable modems and ca- 
ble head-ends. (An offline process binds a certified cable modem with a user account, to 
which Internet usage is billed.) However, special hardware makes installation costly, and u 
special protocols may not be as well scrutinized and secure as standard ones. For example, -j 
the protocol initially used in cable systems did not authenticate the cable head-end, leaving n 
an important security hole. In contrast, //ISPs interoperate with standard LAN cards that 
many users already own (e.g., Ethernet or WaveLAN), and use IETF's standard IPSec proto- 
cols [19]. IPSec is supported by most current operating systems, including Windows 2000, 
NT 5, and Linux. 

• Use of existing online payment method implementations. There are many proposals for on- 
line payment methods (e.g., eCash [9], SET [29], CyberCash [3], IBM Micro Payments [16], 
or Millicent [12]). Some proposals are proprietary and no proposal has achieved wide use. 
Embedding specific online payment methods into //ISP implementations would therefore in- 
volve considerable licensing and maintenance difficulties. These difficulties are avoided by 
//ISP's secure binding of payments received by independently designed and implemented 
processes. 

• Support for offline payment Depending solely on online payment could adversely delay 
//ISP deployment, given that adoption of online payment methods has been slow. Addition- 
ally, offline payment would be quite natural in many scenarios, e.g. when a user checks in at 
an airport, hotel, or conference, or comes into a lounge or cafe. 
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Consequently, the //ISP protocol actually combines several underlying protocols and processes, 
some of which may be offline. 

The /JSP protocol defines the following phases: 



1. Networking configuration. Before a user's computer can communicate with the //ISP, some 
of its networking parameters need to be configured, e.g. the IP addresses of the user's com- 
puter and of the default router. /JSP uses the standard Dynamic Host Configuration Protocol 
(DHCP) [8] to achieve this configuration. 

2. Secure tunnel establishment /JSP uses IPSec's AH protocol in tunnel mode to authenticate 
user packets. The tunnel guarantees that all packets received by the //ISP from a certain IP 
address correspond to the same user. The identity of that user is immaterial to the /JSP, 
provided that the user pays for the /JSP services. Therefore, the user may present a self- 
signed certificate. On the other hand, before paying, users may want to verify that they are 
communicating with a bona fide /JSP. Therefore, //ISPs must present a certificate signed by 
a recognized /JSP certifying authority. Users are also given the options of having the secure 
tunnel (1) use IPSec's AHprotocol to authenticate all packets in transit to the user, and (2) 
use IPSec's Encapsulating Security Payload (ESP) protocol [20] to encrypt all packets in 
transit between //ISP and user. 

3. Control channel establishment. The /JSP needs a secure control channel to send to the user 
the //ISP's price list before payment and a receipt after payment. The user also uses this 
channel to control his or her Internet usage. If the tunnel established in the previous phase 
uses ESP, the control channel is simply a TCP connection; otherwise, the control channel 
uses the TLS protocol [5]. 

4. Contract establishment and binding. In this phase, (1) the //ISP presents to the user a list 
of options for service (e.g., usage metrics; elapsed or usage time, or number of bytes or 
packets transmitted) and payment (e.g., eCash, SET, IBM Micro Payment, or Millicent) and 
the respective prices, (2) the user selects the desired options, (3) the user makes a deposit 
payment, and (4) the //ISP gives a receipt to the user. This phase is skipped entirely if 
the user's computer already has the receipt of an outstanding contract and the user, e.g., is 
reconnecting to the //ISP again after turning his or her computer off. Steps 1 to 3 are skipped 
if the user presents a valid password, received from the //ISP in offline processing of those 
steps (e.g., payment by cash, credit card, or billing to a hotel room account). Step 3 may 
be performed over channels other than the one established in the previous phase (e.g., in the 
case of independent online payment method implementation). However, any online payment 
will necessarily use the tunnel established in phase 2, and therefore can be securely bound 
to it. 

5. Usage metering. Until a user's Internet usage reaches the amount selected in the previous 
phase, the user can send or receive packets to the Internet using the //ISP's facilities. To 
monitor and control his or her usage, the user may exchange messages with the //ISP, using 




the control channel established in phase 3. These messages may, for example, suspend, 
resume, or terminate service. 

6. Settlement When service to a user terminates, the net amount paid by the user should be 
equal to his or her actual usage. If the deposit of phase 4 is greater than the net amount, the 
user may be due a refund. This settlement is performed in this final phase. 

The following sections describe each phase in greater detail. 

3 Networking configuration 

This section describes in greater detail phase 1 of the /JSP protocol. 

In this phase, //ISPs use DHCP for configuring the networking parameters of dynamically 
connected user computers. When user computers boot or restart, they broadcast in the LAN DHCP 
packets requesting configuration. A //ISP server replies with the necessary parameters, including 
network mask and broadcast address, IP addresses of the user's computer and of the default router, 
and possibly the IP addresses of a DNS (Domain Name System) server, NTP (Network Time 
Protocol) server, and line printer server. /JSPs use DHCP's dynamic IP address allocation, so that 
IP addresses assigned to a user's computer remain valid only during a specified lease time. User 
computers must periodically renew their leases to preserve their IP addresses. Expired IP addresses 
may be reused. In //ISPs, the list of unallocated addresses is maintained in FIFO order. 

DHCP makes //ISPs easy to use: A user may, for example, link her laptop to the Ethernet 
or WaveLAN in an airport lounge or conference room, reboot the computer, and automatically be 
configured to access the Internet. DHCP is supported by most current operating systems, including 
Windows 2000, NT, and Linux. 

4 Secure tunnel establishment 

This section describes phase 2 of the //ISP protocol and the use of IPSec [19] in //ISPs. 

IPSec defines two protocols for secure data communication, AH [18] and ESP [20]. These 
protocols are implemented at the network layer and therefore do not require modifications in user 
applications. AH can provide authentication of packet origin, proof of integrity of packet data, 
and protection against packet replay. ESP can provide, in addition to AH's services, encryption 
of packet data and limited traffic flow confidentiality. However, unlike AH's authentication, ESP's 
does not include the packet's source and destination IP addresses. AH and ESP can be used in either 
transport or tunnel mode, as illustrated in Figure 3. Transport mode provides end-to-end security 
between the packet's source and destination. In contrast, tunnel mode encapsulates packets and 
thus provides security between the nodes where the packet is encapsulated and decapsulated. 

//ISPs use the AH protocol in tunnel mode to authenticate all packets received from a user's IP 
address, guaranteeing that the respective address is always used by the same user while the address 
is allocated or bound to a contract. If the user so selects, the //ISP may also use AH in tunnel mode 
to authenticate all packets sent or forwarded to the user. In this case, after the tunnel is established, 
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Figure 3: IPSec packet format depends on protocol (AH or ESP) and mode (transport or tunnel). 
The portion of the packet that is authenticated or encrypted is different for AH or ESP. The encap- 
sulated packet is shown in bold. 



the user may verify the networking configuration performed insecurely by DHCP in the previous 
phase. The authenticated tunnel and the verification of the networking configuration can prevent, 
e.g., DHCP- or DNS-based security attacks against the user on the //ISP's LAN. Another option 
available to users is to use ESP encryption for all packets sent to or received from the user's address. 
This option preserves privacy on the //ISP's LAN. The authentication and encryption options are 
most useful when users are accessing insecure sites on the Internet. A user may not need these 
options, e.g., when he or she establishes another IPSec tunnel within the user's //ISP tunnel to 
communicate securely with an IPSec gateway into the Intranet of the user's employer. In the latter 
case, the nested tunnel may already provide all necessary authentication and encryption. 

Another IPSec protocol, IKE [15], establishes security associations that define the algorithms 
and cryptographic keys used by AH and ESP. Security associations have a specified lifetime, after 
which they are terminated and need to be replaced [19]. The //ISP protocol uses IKE authenticated 
with signatures. The initiator is always the user. Using this method, //ISP and user perform a 
Diffie-Hellman [6] key exchange for securely establishing a shared secret, from which AH and ESP 
keys are derived. Each party then authenticates the other by verifying the other's signature [26] 
on a message containing the other's certificate. A party's certificate contains that party's public 
key, which is necessary for verifying that party's signatures. A party's certificate also contains 
that party's identity and is itself usually signed by a certifying authority (CA) whose public key 
is widely known, so that any party can verify the certificate. Certificate formats are defined, e.g., 
in the X.509 standard [33], Authentication is necessary to prevent "person-in-the-middle" attacks, 
where an intruder would pretend to be the user when communicating with the //ISP and to be the 
//ISP when communicating with the user. Therefore, //ISPs must present certificates signed by a 
recognized //ISP CA, which maintains registration procedures appropriate for such certification. 
In a PKIX-based implementation [17], these certificates would contain a policies extension with 
explicit-text user notice. This notice should be displayed to the user [17] and informs the location 
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and type of LANs supported by the /JSP. On the other hand, the //ISP does not really need to 
authenticate the user's identity in this phase; the //ISP's only requirement is that the user pay 
in phase 4 of the protocol, and that no other user be able to use that payment to gain service. 
Therefore, the //ISP can be configured to accept self-signed user certificates in IKE exchanges. 
Using such certificates, users can remain anonymous. 

IPSec security policies are defined in a Security Policy Database (SPD) per network inter- 
face [19]. Each SPD entry specifies a selector and a rule. Selectors may match, e.g., packets that 
have a certain protocol and source and destination IP addresses and port numbers (ranges and wild 
cards are allowed for these values). Actions may be to drop the packet, bypass IPSec, or apply 
specified IPSec protocols to the packet. The SPD of the LAN interface of //ISP routers is config- 
ured, in the incoming case, to bypass IPSec in the cases of DHCP and IKE packets destined to 
the /JSP, to perform AH and optionally ESP processing to packets whose source address is bound 
(phase 4) to an active contract or whose destination is the /JSP, and to drop remaining packets. In 
the outgoing case, the SPD is configured to bypass IPSec in the cases of DHCP and IKE packets 
whose source is the /iISP, to bypass IPSec or apply AH or ESP processing to packets whose source 
is the //ISP or whose destination address is bound to an active contract, and to drop remaining 
packets. While a user's computer is accessing a //ISP, the SPD of the computer's LAN interface is 
similarly configured, with the incoming and outgoing cases reversed. 

5 Control channel establishment 

This section briefly covers phase 2 j>f the //ISP protocol. 

Because of its uses in the //ISP protocol, the control channel should guarantee message au- 
thenticity and privacy in both directions. Privacy is needed, e.g., to prevent the eavesdropping of 
receipts and their later use by nonpaying users. If the user selected the privacy option in phase 2, 
all communication over the user's tunnel is already secured in both directions by ESP. Therefore, 
the user establishes the control channel by simply opening a TCP connection to a well-known port 
in the /JSP. Otherwise, the tunnel established in phase 2 does not provide all the required security 
(i.e., only authenticates user packets to the /JSP). Therefore, the user employs the TLS [5] pro- 
tocol for establishing a secure control channel over the user's tunnel. The principals of the TLS 
channel are guaranteed to be the same as those of the AH tunnel: The /JSP is authenticated using 
its certificate, while the user is authenticated by AH. 

6 Contract establishment and binding 

This section describes how a contract between //ISP and user is established in offline and online 
cases and how the IP address assigned to the user in phase 1 and secured in phase 2 is bound to the 
user's contract in phase 4 of the /JSP protocol. 1 
The contract is established in four steps: 

frameworks for online price negotiation and payment selection have been discussed in the e-commerce literature 
and there are proposals for their standardization (e.g., JEPI [32] and SEMPER [28]). 
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1. /j,ISP offer. The /iISP presents to the user a contract form containing a serial number, the 
current date and time, available service options, including acceptable usage metrics (e.g., 
elapsed or usage time, or number of bytes or packets transmitted) and the respective prices, 
and acceptable payment methods (e.g., in offline cases: cash, credit card, or billing to an 
account, such as a hotel room account; or in online cases: <?Cash [9], SET [29], IBM Micro 
Payments [16], or Millicent [12]). A contract is always subject to an expiration time. Prices 
may depend, e.g., on whether the user has selected phase 2's privacy option, on the amount 
of usage, on the payment method selected, and on the current or anticipated //ISP load. 

2. User request The user completes the form indicating the desired usage metrics, soft and 
hard usage limits, and payment method. In offline cases, if the payment method is not cash, 
the user physically signs the form. 

3. User deposit. The user employs the selected payment method to deposit with the //ISP an 
amount equal to the selected hard usage limit. If the payment method is credit card or SET, 
this deposit is implemented by an authorization transaction. In certain online cases (which 
do not include SET or eCash), the //ISP may need to allow the user to communicate directly 
with external servers before paying. In IBM Micro Payments [16], for example, the user may 
need to contact his or her issuer to obtain the user's daily certificate, which is necessary for 
making payments. As another example, in Millicent [12], the user may need to contact his or 
her broker to convert broker scrips into //ISP scrips (scrips are Millicent's merchant-issued 
payment instruments). To enable the latter payment methods, modifications in IPSec's SPDs 
may be necessary (e.g., permitting user communication with certain supported issuers or 
brokers for a limited time). 

4. (xISP receipt. The /JSP gives to the user a copy of the contract and password (offline cases) 
or a receipt (online cases). The user commits the receipt to stable storage. The receipt is a 
data structure that includes the contract's serial number, date and time, expiration, selected 
usage metrics and limits, and payment parameters. The //ISP authenticates the receipt with 
a Message Authentication Code (MAC). MAC computation uses a secret key with, e.g., the 
DES-MAC [27], keyed-MD5 [31], or HMAC [1] algorithms. 

Phase 4 of the //ISP protocol is executed as follows. If the user's stable storage contains the 
receipt of an outstanding contract, the user sends the receipt over the control channel to the //ISP, 
which verifies that the contract is still outstanding, is not bound to an IP address, and is not being 
settled. The //ISP then binds the contract with the user's IP address, concluding this phase. Oth- 
erwise, if the user sends over the control channel the password of an unbound outstanding offline 
contract, the //ISP binds the contract with the user's IP address and returns the corresponding re- 
ceipt. The user then commits the receipt to stable storage, concluding this phase. Otherwise, the 
user sends over the control channel a request for online contract establishment, triggering the four 
steps described above. The contract is bound to the user's IP address in step 4. 
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Figure 4: Contract states and transitions. The initial states are the top ones. 



7 Usage metering 

This section describes phase 5 of the //ISP protocol, usage metering. Metering depends on contract 
and IP address states. Therefore, this section discusses the possible states and the events that trigger 
state transitions (e.g., user commands). 

Metering is greatly simplified when the usage metric is elapsed time. In such cases, the /JSP 
does not need to commit contract state and usage to stable storage in order to be able to recover 
from /JSP crashes: The receipts themselves contain all the necessary information. If the //ISP's 
shared link to a conventional ISP is charged on a similar basis, this is probably the best alternative. 
However, if the /JSP is charged according to number of bytes or packets transmitted, it may need 
to do the same with respect to its clients. 

In general, users monitor and control contract state by sending commands to the //ISP. Avail- 
able commands include report usage, start/resume, suspend, or terminate a contract, and extend a 
contract's soft limit up to its hard limit. The //ISP replies to these commands include the accumu- 
lated usage and the soft and hard limits. The //ISP may also send asynchronous warning messages 
when a contract's accumulated usage reaches its soft or hard limit or expires, or when a user on 
a different IP address presents the contract's receipt on phase 4 of the //ISP protocol. All these 
messages contain the contract's serial number and are sent over the control channel. 

A contract is outstanding between its establishment and settlement, and becomes extinguished 
when it expires, has accumulated usage that reaches its hard limit, or after settlement, as shown 
in Figure 4. An outstanding contract can be unbound, bound, or in settlement. An outstanding 
contract is initially unbound. An unbound contract becomes bound to an IP address when a receipt 
for that contract is sent to or from that IP address in phase 4 of the //ISP protocol. A bound 
contract becomes unbound when the user's computer lets the respective DHCP lease or IPSec 
security association expire (e.g., because of a crash). An unbound or bound contract becomes in 
settlement when the user issues a terminate command. 

A bound contract can be suspended, active, or delinquent. A bound contract is initially sus- 
pended. A suspended contract becomes active when the user issues a start/resume command. An 
active contract becomes suspended when the user issues a suspend command, and becomes delin- 
quent when the usage reaches the soft limit. A delinquent contract becomes active when the user 
issues a valid extend command. 
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Figure 5: IP address states and transitions. The initial state is unallocated. 



An IP address can be unallocated, allocated, or bound to a contract, as shown in Figure 5. 
IP addresses are initially unallocated. An unallocated IP address becomes allocated when DHCP 
allocates it to a user's computer. An allocated IP address becomes unallocated again if the user's 
computer allows the respective DHCP lease or IPSec security association to expire. An allocated 
IP address becomes bound to a contract when the converse is true. A bound IP address b becomes 
unallocated when the respective contract becomes unbound or extinguished or (1) a user on a 
different IP address d presents the contract's receipt on phase 4 of the //ISP protocol; and (2) the 
//ISP repeatedly warns b but b does not respond, which suggests that the user's computer crashed 
and is now recovering on a different address. 

The //ISP meters a contract's usage time only while the contract is active. The //ISP router 
forwards to or from the Internet and meters the number of bytes or packets only of packets that 
use an IP address bound to an active contract. The //ISP also allows packets whose source or 
destination is the //ISP. 



8 Settlement 

This section describes phase 6 of the //ISP protocol. This is the final phase. 

If the user lets the contract expire or uses the contract fully to its hard limit, the //ISP retains 
the whole deposit. If the payment method is credit card or SET, the //ISP automatically performs 
a settlement transaction for that value. On the other hand, if the usage is below the hard limit, 
an adjustment or refund is necessary, and will be processed according to the payment method. In 
offline cases other than cash, the user physically signs a new form. In the credit card and SET cases, 
a settlement transaction for the value of the actual usage is performed. In the cash, eCash [9], and 
Millicent [12] cases, a refund is returned to the user. In the cases of offline billing to an account 
and of IBM Micro Payments [16], the /JSP simply adjusts its billing records. 
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9 NAPT (Network Address Port Translation) 



/xISPs have to allocate one IP address per contract that is bound or in settlement. In order to get 
more than one IP address from a conventional ISP, the ^uISP will typically need to pay extra. A cost- 
saving alternative is to have the jl/ISP router implement NAPT (Network Address Port Translation) 
[30] so that all //ISP users share a single global IP address. However, NAPT may not support 
certain protocols, as discussed in this section. 

If a /iISP implements NAPT, the IP addresses that it allocates to user computers are private 
(unregistered and possibly not globally unique) [25]. NAPT translates respectively the source 
or destination IP addresses and port numbers (between private and global) in packets sent to or 
received from the Internet. NAPT builds a translation table such that all local hosts share the same 
global IP address, and destinations of packets received from the Internet can be determined by the 
global port numbers. 

NAPT is not transparent to application-layer protocols that include host addresses or port num- 
bers within their pay loads (e.g., FTP). For each such protocol, NAPT requires a corresponding 
Application Level Gateway (ALG) that knows how to modify the application-level payloads. ALG 
support has been increasing, but NAPT may still not interoperate with certain protocols [30]. 

NAPT is also not transparent with respect to most of IPSec's protocols and modes. (How- 
ever, note that NAPT does not affect the AH tunnel used in the /xISP protocol, which terminates 
at the router.) NAPT address translations invalidate AH's authentication, whose scope includes 
the source and destination addresses. NAPT address translations can also invalidate TCP or UDP 
checksums of ESP packets in transport mode, which are calculated including the packet's source 
and destination addresses. An ALG for these cases is not possible because it would need to know 
the cryptographic keys used, which would violate end-to-end security. NAPT can, however, inter- 
operate with ESP in tunnel mode, where the entire packet is encapsulated and NAPT's translations 
do not affect the encapsulated checksum. VPN Masquerade [14] is a NAPT implementation that 
provides such support. VPN Masquerade uses a number of heuristics for demultiplexing incoming 
traffic. These heuristics are subject to race conditions and may, in some cases, fail, causing packet 
misdelivery. However, packet misdelivery does not break security any more than eavesdropping in 
the LAN would. 

We recently proposed [2] a DHCP extension that allows hosts to lease from NAPT, e.g., global 
IP addresses and port numbers. Using that extension, IPSec implementations can always interop- 
erate correctly with NAPT. Another alternative currently being considered is to replace NAPT by 
RSIP (Realm-Specific IP) [30]. We believe that either solution will go a long way toward elimi- 
nating NAPT's current interoperation difficulties. Therefore, the cost-reducing option of using a 
single global IP address in jzISPs may soon become even more attractive. 

10 Other design variations 

Many details is the jzISP design can be altered without essentially impacting in the overall func- 
tionality. This section discusses some of the possible modifications. 



13 



An obvious variation is to use another protocol for authentication and/or encryption in the 
secure tunnel. The new protocol must be able to encapsulate and decapsulate packets. For example, 
instead of AH, a j/ISP might employ ESP's authentication option to authenticate packets sent by 
paying users. In either case, ESP's encryption is optional, and tunnel mode is used. Unlike AH, 
ESP's authentication does not cover the packet's source and destination IP addresses. However, 
ESP's authentication does cover the entire encapsulated packet. Therefore, ESP's authentication is 
sufficient for spoofing prevention [13]. 

Another variation would be to set up the control channel before the secure tunnel. The control 
channel might allow, for example, the transmission of cryptographic keys to be used in the tunnel. 
In this case, IKE authentication could, e.g., use a pre-shared key, instead of digital signatures. 

Other variations include using a solution other than the DHCP protocol for configuring net- 
working parameters of user computers; using a solution other than the IKE protocol for estab- 
lishing the secure tunnel's cryptographic algorithms and keys; using a firewall, instead of IPSec's 
SPDs, for dropping packets of nonpaying users; or using a protocol other than TLS (e.g., SSL [11]) 
for the secure control channel. 

11 Performance 

An important practical question is how powerful a computer would be necessary for implementing 
a ^ISP router/server. To answer this question, we built a PC-based /xISP router/server prototype 
and report its performance in this section. 

Our prototype is based on a low-cost PC with a 400 MHz Pentium II CPU and 64 MB of 
main memory. The prototype uses the freely available Linux 2.2.12 operating system and the 
FreeS/WAN 1.1 IPSec implementation [10]. 

To circumvent limitations of our prototype environment, we used several of the design alter- 
natives discussed in the previous section. First, we used SSL instead of TLS because we had 
an SSL implementation easily available. Second, the prototype uses SSL to establish the control 
channel before the secure tunnel, because FreeS/WAN 1.1 does not fully implement IKE. The 
control channel securely transmits randomly generated keys for FreeS/WAN authentication using 
pre-shared keys. 

We connected a client and a server Linux PCs to the /iISP prototype using separate 10 Mbps 
Ethernets, and measured the TCP throughput between the client and server. For control, we also 
measured the TCP throughput between client and server when connected on the same 10 Mbps 
Ethernet (without the /iISP): 6.4 Mbps. When client and server were connected through the proto- 
type implementing only routing and NAPT (no //ISP functionality), the TCP throughput dropped 
slightly to 6.2 Mbps, and the CPU utilization on the prototype was 4%. With /iISP functionality 
and packet authentication between client and //ISP (using AH with MD5 [22]), 2 the TCP through- 
put between client and server was 5.8 Mbps and the CPU utilization on the prototype was 26%. 
Finally, with /zISP functionality and both authentication and encryption between client and //ISP 

2 For ease of implementation, AH was used in both directions. Results would probably improve significantly if AH 
were used only from client to jxISP, as described in Section 4. 
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(using ESP with MD5 and triple DES [21]), the TCP throughput between client and server was 5.3 
Mbps, and the CPU utilization on the prototype was 70%. 

We also measured the time necessary for a client to connect to the //ISP prototype (steps 1 to 
4 of the //ISP protocol), as well as the load imposed on the prototype's CPU by such connections 
(with no other network or CPU activity). We simultaneously started connections from two 100 
MHz Pentium clients and one 700 MHz dual-processor Pentium III client. Connection took 0.5 
s for the fast client and 1.9 and 2.1 s for the slow clients. The prototype CPU was 31% utilized 
during these connections. 

These measurements suggest that even a modest PC can handle the loads that may be expected 
on a //ISP router/server. Access links such as Tl, DSL and cable provide bandwidths from 0.6 
to 7 Mbps downstream and from 0.6 to 1.5 Mbps upstream (cable can theoretically support up 
to 27 Mbps downstream, but cable modems usually limit a client's bandwidth to 1 Mbps). Such 
bandwidths are one to two orders of magnitude greater than those enabled by PSTN (57 Kbps 
downstream and 33 Kbps upstream), but still represent only a moderate load for today's processors. 

The measurements also justify charging a premium price for privacy on the //ISP's LAN: ESP's 
authentication (MD5) and encryption (triple DES) imposed a much higher load on the //ISP proto- 
type than did AH's authentication (MD5) alone. 

12 Summary 

We described //ISP, a novel architecture that allows Internet access services to be securely provided 
and charged over standard shared-medium LANs, e.g. Ethernet or WaveLAN. Such LANs can be 
easily installed in convenient locations, e.g. airports, hotels, conference centers, lounges, and cafes. 
Standard protocols automatically configure user computers so that they can access the Internet. A 
router connects the //ISP LAN to a shared high-bandwidth access link (e.g., DSL or cable) to 
a conventional ISP. Because a //ISP amortizes the cost of the access link among many users, it 
can also reduce the cost of Internet access in offices and apartment buildings. The bandwidth 
dynamically allocated to each user is likely to be similar to that enjoyed by many users at work, 
and much better than that provided by a dial-up PSTN line. The architecture supports a variety 
of payment methods, both offline (e.g., cash, credit card, or billing to a hotel room account) and 
online (e.g., eCash, SET, IBM Micro Payments, or Millicent). //ISPs use IPSec's IKE protocol for 
securely exchanging authentication keys with paying users. Paying users use IPSec's AH protocol 
in tunnel mode to authenticate each packet they send. Therefore, //ISPs can easily detect and drop 
packets of nonpaying users. A /JSP must present to users a certificate signed by a recognized //ISP 
certifying authority. However, /ilSPs can accept users who do not have a certificate by a recognized 
authority or who choose to remain anonymous, as long as those users provide valid payment. The 
//ISP protocol can use independent online payment method implementations because, regardless 
of how online payment is implemented, it runs on the user's authenticated tunnel, and therefore can 
be securely bound to it. The //ISP protocol allows users to monitor and control usage and supports 
recovery in case of a /JSP or user computer crash. 
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